feat(web): navigate queued messages without losing unsaved edits - #12892

In file @apps/server/src/project/ProjectService.ts around line 396:

`deleteProject` can soft-delete a project while leaving a newly created live V2 thread attached to it, along with that thread’s run/provider-session resources. Because `projectThreads` comes from the one-time shell snapshot at line 389, a `thread.create` committed before the project deletion at line 471 is never locked or cleaned up; re-read and serialize membership immediately before committing the project deletion, or reject and retry when the child set changes.

In file @apps/server/src/project/http.ts around line 55:

Deleting a project through this HTTP `mutate` endpoint leaves any tracked background clone running, so it can finish into the removed project's destination and retain its unfinished checkout. Unlike the WebSocket mutation path, `projectMutationOperation` does not trigger `ProjectCloneTracker.discard` after a successful `project.delete`; invoke that cleanup for HTTP deletes as well.

In file @apps/server/src/orchestration-v2/Orchestrator.ts around line 8449:

A failed, interrupted, or rolled-back delegated wake is marked `delivered`, so its claimed tasks are not included in `pendingTaskIds` and no successor wake is reserved; the parent therefore never receives the child result. Only `completed` should settle these tasks as delivered; all other terminal statuses must return them to `pending`.

In file @packages/contracts/src/orchestrationV2.ts around line 2553:

`queued-run.edit` cannot clear a queued message's context, so removing the final context-linked attachment leaves stale context that is later delivered with the message. Because `context` is optional here, the mobile edit flow omits it when the replacement is empty, and the dispatcher interprets omission as “leave unchanged.” Use a nullable replacement (or another explicit clear operation) to distinguish clearing context from leaving it unchanged.

Also found in 1 other location(s):
- apps/server/src/orchestration-v2/Orchestrator.ts:7121 -- Queued edits cannot clear message context. `queued-run.edit` treats an omitted `command.context` as “leave the old context”, but `resolveQueuedEditPayload` deliberately returns `context: undefined` after attachment-linked records are removed (mobile state `queued-run-edit.ts` lines 107-141). The client then omits the field (`editQueuedRun` only includes it when truthy), so this payload retains the previous context, including references to attachments just removed. Persist an explicit context replacement/clear operation (or clear it whenever an attachment replacement has no context) so edited queued messages do not later execute with stale context.

In file @apps/server/src/orchestration-v2/Orchestrator.ts around line 9061:

A transient failure in `handleTerminalRun` permanently drops terminal processing: if `finalizeAppOwnedSubagent` or queue promotion fails, the child result and wake are never applied until a server restart. The same loss occurs when the startup `subagent-results` or `delegated-completions` recovery scan fails, because those results predate the live subscription cursor. Retry failed terminal handling and recovery work with durable or otherwise retained state instead of only logging the error in this catch.

In file @apps/server/src/mcp/WorktreeMcpService.ts around line 247:

Cancelling during `createWorktree` can leave the newly created branch and worktree on disk without a thread binding. `restore(...)` remains interruptible until `createWorktree` returns, but the rollback is only established afterward in `recheckAndBind`; make the post-add acquisition path uninterruptible or register cleanup before acquisition can be cancelled.

In file @apps/server/src/provider/acp/AcpClientPolicy.ts around line 327:

Accepting any `command` permission sets `grants.execute = true`, so every later client-mediated `terminal/create` in that scope is authorized regardless of the command the user approved. A provider can get approval for one benign command and then run an unrelated command with the T3 server's privileges; the grant must be bound to the approved command (or terminal execution must require a separate matching approval).

In file @apps/server/src/orchestration-v2/Orchestrator.ts around line 4275:

Every `message.dispatch` with a valid `sourcePlanRef` is rejected as `Proposed plan ... does not exist`, so plan-based dispatch cannot run. `getProjectionWithPendingEvents` uses `readCommandProjection`, which constructs projections with `plans: []`; load the plans into that projection before this lookup.

In file @apps/server/src/provider/acp/AcpRegistryProbe.ts around line 382:

URL-authentication requests with elicitation IDs from 129–256 characters are declined, so the probe fails instead of presenting the browser-login action. Both `probeAcpRegistryConfiguration` and `makeAcpRegistryManagementRuntime` use `boundedOpaqueValue(..., MAX_ID_LENGTH)` (128), although `AcpRegistryUrlAuthAction` and the ACP adapter support IDs up to 256; validate these IDs against the action contract's 256-character limit.

In file @apps/server/src/orchestration-v2/Orchestrator.ts around line 1783:

When the last task in a delivery is acknowledged or disposed after its delivery run has completed, `parentRun.delegatedCompletion.delivery` remains non-null with an empty `taskIds`, so later terminal child completions cannot reserve a successor wake and never wake the parent. `clearDelivery` only clears an absent or `queued` delivery run; clear or advance exhausted terminal deliveries as well so every child terminal state satisfies `completionWake: "always"`.